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ABSTRACT 


For the Hyper- X/X-43A program, the development of a comprehensive validation test plan 
played an integral part in the success of the mission. The goal was to demonstrate hypersonic 
propulsion technologies by flight testing an airframe-integrated scramjet engine. Preparation for 
flight involved both verification and validation testing. By definition, verification is the process 
of assuring that the product meets design requirements; whereas validation is the process of 
assuring that the design meets mission requirements for the intended environment. This report 
presents an overview of the program with emphasis on the validation efforts. It includes topics 
such as hardware-in-the-loop, failure modes and effects, aircraft-in-the-loop, plugs-out, power 
characterization, antenna pattern, integration, combined systems, captive carry, and flight testing. 
Where applicable, test results are also discussed. The report provides a brief description of the 
flight systems onboard the X-43A research vehicle and an introduction to the ground support 
equipment required to execute the validation plan. The intent is to provide validation concepts that 
are applicable to current, follow-on, and next generation vehicles that share the hybrid spacecraft 
and aircraft characteristics of the Hyper-X vehicle. 

NOMENCLATURE 


AIL 

aircraft-in-the-loop 

ATK-GASL 

Alliant Techsystems, Inc., General Applied Scientific Laboratory Division 

BIT 

built-in-test 

CD ATS 

Configurable Data Acquisition Test Software 

CST 

combined systems test 

Decom 

decommutation computer 

DFRC 

Dryden Flight Research Center 

ECTOS™ 

Embedded Computer Toolbox and Operating System 

EFS 

engine and fluid system 

EMA 

electromechanical actuator 

EMAC 

electromechanical actuator controller 

EMC 

electromagnetic compatibility 

EMI 

electromagnetic interference 

FADS 

Flush Airdata System 

FMET 

failure modes and effects testing 

FMU 

flight management unit 

FRR 

flight readiness review 

FSC 

fuel servicing cart 

FTS 

flight termination system 

GH2 

gaseous hydrogen 



GN2 

gaseous nitrogen 

GPS 

global positioning system 

GSE 

ground support equipment 

GTP 

ground test panel 

HIL 

hardware in-the-loop 

HXA 

Hyper-X adapter 

HXLV 

Hyper-X launch vehicle 

HXRV 

Hyper-X research vehicle 

ICD 

interface control document 

IMU 

inertial measurement unit 

INS 

inertial navigation system 

I/O 

input/output 

IPT 

integrated product team 

IS 

instrumentation system 

ISRS 

Inertial Sensor Recorder/Simulator 

ITAS 

integrated telemetry analysis system 

MCV 

motorized control valve 

MDL 

mission data load 

NAV 

navigation 

ODM 

ordnance driver module 

OFP 

operational flight program 

OSC 

Orbital Sciences Corporation 

PC 

personal computer 

PCM 

pulse code modulation 

PDS 

power distribution system 

PID 

parameter identification 

POPU 

push-over pull-up 

PPT 

precision pressure transducer 

PSC 

propulsion system control 

PWM 

pulse width modulation 

QA 

quality assurance 

RF 

radio frequency 

RT 

remote terminal 

Sep 

separation 

SID 

simulation interface device 
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SiH4 

silane 

SV 

solenoid valve 

TPS 

thermal protection system 

VBA 144 

Hyper-X vehicle, aft bulkhead station 144 

VBA 215 

Hyper-X rear adapter bulkhead station 215 

VDC 

volts of direct current 

VDD 

version description document 

VPL 

variable parameter load 

VME 

Versa Module Eurocard 

VMS 

vehicle management system 

a 

angle of attack, deg 

P 

angle of sideslip, deg 

V 

heading angle, deg 


INTRODUCTION 

The Hyper-X vehicle presented several challenges in the development of a comprehensive 
validation plan. The vehicle encompassed the characteristics of a spacecraft, including autonomous 
operation and launch vehicle integration, plus characteristics of an aircraft, such as control surfaces 
and air-breathing propulsion. To address these attributes, the validation program combined standard 
aerospace integration techniques with additional unique validation tests to ensure test coverage 
and minimize program risk. This report will provide details of the validation program, including 
hardware-in-the-loop and aircraft-in-the-loop testing methods. For completeness, an overview of 
the system design and the verification process is included. A summary of the lessons learned during 
the validation planning and execution is also provided. The information presented is intended 
to assist in the development and execution of validation programs for aerospace vehicles with 
characteristics similar to those of the Hyper-X. For this report, the terms HXRV and X-43A are 
synonymous and used interchangeably to identify the Hyper-X research vehicle. 

Project Overview 

The purpose of the Hyper-X program was to demonstrate the operation of an 
airframe-integrated scramjet engine at Mach 7 and Mach 10 flight conditions (ref. 1). Three 
test flights were planned: two at Mach 7 and one at Mach 10. The Hyper-X research vehicle 
(HXRV), depicted in figure 1, is a 12-ft long, 5-ft wide, autonomously controlled aircraft with 
2 all-moving wings and 2 rudder control surfaces. The 2 research vehicles designed to fly at Mach 7 
weighed 2737.70 and 2773.88 lb, respectively. The third research vehicle weighed 2823.16 lb. The 
Hyper-X adapter (HXA), designed specifically for the Hyper-X program, was used to mate the 
research vehicle to the Hyper-X launch vehicle (HXLV). The HXLV is a single-stage Pegasus® 
(Orbital Sciences Corporation (OSC), Chandler, Arizona) rocket launch vehicle that was used to 
boost the HXRV to its flight test conditions. The combination of the HXRV, HXA, and HXLV 
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formed the full X-43A stack, as shown in figure 2. The stack was carried to the launch point by the 
NASAB-52B (The Boeing Company, Chicago, Illinois) airplane, tail number 008. 




Length: 12 ft 4 in. 
Width: 5 ft 0 in. 

Height: 2 ft 2 in. 

Weight: 3000 lb max 


Rudder- 



Figure 1. The Hyper-X research vehicle. 



Figure 2. Full X-43A stack configuration. 
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The HXRV was delivered to the test condition in two phases. The first phase was the drop 


from the B-52B airplane that air-launched the full stack at a predetermined position, airspeed, and 
altitude over the Point Mugu Naval Test Range, off the coast of California. The second phase was 
the HXLV boost that took the stack to the predetermined flight test Mach number, dynamic pressure, 
and angle of attack. After stack separation, the HXRV flew autonomously for the remainder of the 
mission. The engine experiment was performed first, followed by a controlled descent until the 
vehicle impacted the Pacific Ocean (ref. 2). The HXRV was not recovered. A map of the Mach 7 
trajectory is shown in figure 3. 



nmi nmi nmi nmi nmi nmi 
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Figure 3. The X-43A Mach 7 trajectory. 


The HXRV was designed by the NASA Langley Research Center in Hampton, Virginia. 
It was fabricated by Alliant Techsystems, Inc., General Applied Scientific Laboratory Division 
(ATK-GASL), in Tullahoma, Tennessee, which also fabricated and performed system integration 
for each of the HXRVs including installation, wiring, and verification testing. This included basic 
interface testing such as continuity checks, load checks, and instrumentation checks. Through 
subcontract to ATK-GASL, Boeing North American (Huntington Beach, California) developed 
and conducted verification testing on the HXRV flight software while NAS A performed validation 
testing on the HXRVs. The integration of each HXRV to an adapter was also done by NASA and 
included validation of the electrical and fluid systems interfaces. Orbital Sciences Corporation 
provided the HXLVs and performed both the verification and validation testing of the HXLVs, 
and NASA and OSC shared responsibilities for validating system interfaces during full stack 
integration and B-52B mate. 
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Each integrated research vehicle was delivered to the NASA Dryden Flight Research Center 
(DFRC) in Edwards, California, to undergo final system integration and validation testing. Design 
of the ground test equipment began at the same time as validation test planning. This approach 
ensured that the functions necessary to accomplish the validation requirements were implemented 
in the test equipment. The validation testing comprised a series of procedures, increasing in 
complexity, which evaluated system response to simulated flight scenarios. 

Each test vehicle was subjected to predictable failure conditions to evaluate the response of 
safety and mission critical systems. Simulations and flight hardware were run through nominal 
and off-nominal test cases to assess hardware and software performance and repeatability. For 
these types of tests, the simulation bench, consisting of a simulation computer and a ground test 
interface, was used to monitor and control all flight computer input and output signals. Inertial 
sensor data was simulated to create real mission trajectories. Additional test equipment was used 
to validate vehicle safety and performance without simulation. 

HYPER-X SYSTEM DESCRIPTION 

The HXRV, shown in figure 4, was composed of the following major systems: the power 
distribution system (PDS), the vehicle management system (VMS), the instrumentation system 
(IS), and the engine and fluid system (EFS) (ref. 3). The research vehicle was separated from the 
stack by way of a separation system within the HXA. The HXRV was equipped with a thermal 
protection system (TPS), made from alumina-enhanced ceramic tiles that shielded the vehicle 
systems from high temperatures encountered during hypersonic flight. Figure 5 shows how the 
HXRV flight systems interfaced with the other Hyper-X elements. An overview of the HXRV 
hardware, software, and ground support equipment (GSE) used for validation testing is provided 
in the following section. 
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Figure 4. Hyper-X research vehicle flight systems. 
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Figure 5. Hyper-X system block diagram. 
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The Power Distribution System 


The PDS provided 28 V and 150 V of direct current to the HXRV. The 28 V bus powered the 
HXRV avionics and the 150 V bus powered the actuator motors. During the free-flight portion of 
the mission, source power for the PDS was supplied by an onboard silver-zinc battery (ref. 3). The 
28 V battery capacity was approximately 6 amp-hours, and the 150 V battery capacity was 7 amp- 
hours. Both battery sets were combined into a single chassis. During ground checkout and captive 
flights, power to the vehicle was delivered by either the GSE or the B-52B airplane. 

The Vehicle Management System 

The VMS managed the vehicle guidance, navigation and control functions, in addition to the 
operation of the engine fluid systems. The VMS consisted of a flight management unit (FMU), 
five electromechanical actuators (EMAs), an electromechanical actuator controller (EMAC), and 
a Flush Airdata System (FADS). The FMU and FADS were manufactured by Honeywell, Inc. in 
Clearwater, Florida. The EMAs and EMAC were manufactured by Moog Inc., in East Aurora, 
New York. 

The FMU contained a mission computer, an inertial measurement unit (IMU), a global 
positioning system (GPS) receiver, a MIF-STD-1553 data interface, and three digital and analog 
input/output (I/O) boards. It was a modified version of the guidance and navigation unit used on 
the U.S. Navy’s Standoff Fand Attack Missile-Expanded Response (SFAM-ER) program. The 
FMU mission computer software hosted the guidance and flight control laws, propulsion system 
control algorithms, mission moding logic, system control, and health monitoring functions. A pair 
of MIF-STD-1553 buses connected the FMU to the instrumentation system so that FMU-related 
data could be downlinked to the ground. It was designed to operate only in the broadcast mode 
(ref. 3). In the ground mode, the FMU could be configured as a bus controller or a bus monitor. 
In flight mode, the FMU operated as a bus controller and the instrumentation system as a ‘receive 
only’ bus monitor. 

For the actuation system, five EMAs were managed by a single actuator controller. Four 
of the actuators were used to move the aerodynamic surfaces (two all-moving wings and two 
rudders), and the fifth actuator opened and closed the engine cowl door. The control, position 
feedback, current feedback, and motor brake functions of the system operated on the 28 V side of 
the PDS. The actuator motor power was drawn from the 150 V side. 

The FADS system (ref. 4) consisted of nine precision pressure transducers (PPTs) that were 
plumbed to flush ports on the wedge-shaped nose of the HXRV to collect pressure data. It was 
used to assess the FADS algorithms that estimated angle of attack and dynamic pressure. During 
the Mach 7 postengine experiment phase, the FADS estimated angle of attack augmented the 
FMU measured inertial angle of attack. During other phases of the mission, data from the FADS 
system was treated as research data and was not used for any type of flight control enhancement 
because the FADS algorithms lacked maturity (ref. 5). For the entire flight 3 mission, the FADS 
system was treated only as research data because algorithm reliability was uncertain above 
Mach 8 (ref. 6). 



The Instrumentation System 


The IS contained multiple digital and analog inputs and interfaced with all of the X-43A 
systems to collect data from various instruments (ref. 3). It processed over 700 unique parameters 
contained within the instrumentation data stream. Data from the IS was downlinked to the ground 
through three separate S-band antennas. Two antennas, one on the starboard side and the other 
on the port side of the vehicle, were controlled by a single 20-watt transmitter. An independent 
10-watt transmitter controlled the third antenna, mounted on the aft bulkhead. Instrumentation data 
was also routed to the aft bulkhead via an RS-422 bus so that a direct connection could be made 
with ground test equipment to support monitoring functions. The vehicle was tracked during flight 
tests through the use of a 200-watt C-band transponder located in the vehicle. 

The Engine and Fluids System 

The EFS consisted of a supersonic combustible ramjet (SCRAMJET) engine, a fuel system, 
an ignitor system, a coolant system, and a purge system. The engine had an inlet cowl door, fuel 
injectors, and a combustion chamber. The cowl door was closed during captive carry and boost 
to minimize heat load on the cowl lip and the interior of the engine. It was opened to perform the 
engine test and then closed again for the remainder of the free flight. 

The fuel system was a blowdown system that used gaseous hydrogen. The ignitor system 
was a blowdown system that contained a pyrophoric mixture of 20 percent silane and 80 percent 
gaseous hydrogen by volume (ref. 7). Critical data from these two systems and the engine were fed 
into the FMU and rebroadcast continuously until the vehicle impacted the ocean. 

The coolant system was also a blowdown system. It used glycol-water in the HXA and water 
in the HXRV to provide conductive cooling to the engine components. During the boost and 
experiment phase, the cowl lip and engine sidewalls were actively cooled (ref. 7). 

The purge system used gaseous nitrogen to provide several functions. It continuously purged 
the HXRV body cavity of oxygen during free flight, and acted as the tank pressure to the coolant 
system. The nitrogen was also used to purge and inert the hydrogen and silane tanks after the 
experiment phase, or during emergencies in which the tanks are vented in a controlled fashion by 
the FMU. 

Each fluid system had a main isolation solenoid valve (SV). For the hydrogen and silane 
systems, motorized control valves (MCVs) were used to control mass flow. Both types of valves 
were controlled by the VMS. To provide flight safety and added protection from inadvertent fuel 
release, the hydrogen and silane isolation SVs were electrically inhibited through switches located 
at the HXRV monitor station in the B-52B airplane. In addition, fuel jettison could be commanded 
from the monitor station if the hydrogen and silane systems had to be manually vented. 
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The Separation System 


The mechanical separation system, located in the HXA, consisted of four pyrotechnic 
separation bolts, a rotating drop jaw, and a B-l (Rockwell International, Milwaukee, Wisconsin, 
now The Boeing Company, Chicago, Illinios) ejector rack. The separation bolts held the research 
vehicle to the HXA. The ejector rack was originally used for B-l weapons deployment, but was 
modified for use on the HXA to push the HXRV away from the stack. The redundant ordnance 
wiring and initiation components were controlled by the HXLV ordnance system. 

The separation sequence is described as follows. When the full stack reaches the separation 
window, the HXLV sends a “ready to separate” discrete signal to the HXRV FMU. The HXRV 
begins its purge and cooling flow, and the FMU sends a “separate command” signal to the HXLV 
three seconds later. The launch vehicle ordnance driver module (ODM) then initiates the bolts and 
ejector rack ordnance. The separation bolts are detonated, releasing the HXRV from the HXA. The 
ejector then pushes the HXRV away from the HXA. Within the HXRV, the separation sense wires 
break, and the FMU detects this signal loss as a successful separation. 

The original HXA design incorporated the use of a drop jaw in an effort to clear the adapter from 
the HXRV during the separation event. However, extensive wind tunnel data of the aerodynamic 
interaction between the HXRV and the HXA drop jaw during the separation revealed that the 
disturbances created by rotating the drop jaw were worse than leaving it stationary. The change to 
make the jaw fixed was implemented just before first flight. 

Flight Software 

The HXRV flight software consisted of multiple components. The operational flight program 
(OFP) consisted of the project-specific flight code that was developed in the Ada programming 
language. The propulsion system control (PSC) and flight control laws were developed in MATLAB® 
Simulink® (The Math Works, Natick, Massachusetts) and later auto-coded and compiled into the 
OFP executable in the C programming language. Honeywell, Inc. provided the software kernel and 
inertial navigation code, called ECTOS™ (Embedded Computer Toolbox and Operating System). 
The software architecture was driven by the vehicle mode, as shown in figure 6. The mission mode 
was controlled by external discrete inputs from the GSE and the separation event discrete signals. 
The mode control bits were only considered valid during the indicated mode. For example, the 
propulsion and flight control laws did not become active until the preseparation mode. In support 
of flight and ground test operations, two uploadable configuration files were used. They were the 
mission data load (MDL) and the variable parameter load (VPL). The MDL allowed the upload of 
classified engine parameters, GPS initialization data, and predetermined separation slope, control 
surface bias, and control loop timing values, while the VPL allowed a selection of 32 parameters 
for downlink that were not available in the nominal FMU 1553 telemetry stream. For verification 
of the current version of software installed, the telemetry stream included checksums of the kernel 
and OFP build. 
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Figure 6. Mission moding diagram. 


TEST CONFIGURATION AND GROUND SUPPORT EQUIPMENT 

The Hyper-X GSE was designed to meet the needs of the validation test program. Depicted 
in figure 7, the standard test configuration was adaptable to meet the requirements for individual 
tests. The following sections provide an overview of the GSE components. 
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Figure 7. Validation test configuration. 


The Simulation Bench 

The main function of the simulation bench was to provide simulated in-flight conditions to 
the HXRV VMS during ground based testing. It was used for hardware-in-the-loop (HIL) and 
aircraft-in-the-loop (AIL) testing. Since the bench was mounted inside a mobile trailer, it could 
be transported to any test location. The simulation bench consisted of the simulation computer, 
the Inertial Sensor Recorder/Simulator (ISRS) and Configurable Data Acquisition Test Software 
(CDATS) computers (Honeywell, Inc.), and the Simulation Interface Device (SID). Figure 8 shows 
the simulation bench configuration. 
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Figure 8. Hyper-X simulation bench: ISRS (left), simulator (center), SID (right). 


The simulation computer was a 400 MHz Sun Microsystems (Santa Clara, California) 
UltraSparc® station that ran the simulation software at 200 Hz and served as the user interface. 
Through the use of models, the computer had the ability to simulate the following systems: 
engine, fuel, ignitor, cooling, purge, actuation, aerodynamics, mass properties, PSC, and guidance, 
navigation and control. The user had the option of choosing which systems were to be simulated 
and which ones were to utilize the real flight hardware. 

The simulation computer provided incremental velocity, acceleration, pitch, and pitch rate 
information to the ISRS PC, which relayed that data to the FMU via an RS-422 serial link to simulate 
the motion of the vehicle. The CD ATS computer handled the FMU 1553 data for monitoring and 
archiving purposes. It was also used to upload the flight OFP, MDL, and VPL to the FMU. 

The bench was connected between the FMU and the rest of the HXRV systems through the 
use of an SID. It handled all input and output signals via two VME chassis containing a custom 
relay card, analog to digital (A/D), digital to analog (D/A), and discrete I/O boards. To provide 
more flexibility, analog or discrete channels could be individually configured. For each analog 
channel, the user could choose to pass the signal through (with or without voltage monitoring), 
open the circuit, or send the simulation model output to the FMU or any other HXRV system. For 
each discrete channel, the user had the choice of passing the signal through, opening the circuit, or 
setting/resetting the 28 V discrete signals. 
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The Hyper-X Research Vehicle Monitor Station 


Located on the lower deck of the B-52B airplane, the HXRV monitor station was primarily used 
for monitoring HXRV health and safety parameters during mission flights and B-52B integrated 
tests. This monitoring panel, shown in figure 9, provided discrete control of the HXRV safety and 
mission critical functions. They included system pressures, actuator built-in-tests (BIT), vehicle 
power control, fuel vent/purge, and fluid system valve inhibits. In addition to the panel, there was 
a telemetry decommutation computer on the B-52B airplane that received telemetry directly from 
the research vehicle and displayed the status of critical parameters to the flight test engineer. 



Figure 9. The HXRV monitor station. 


The Ground Test Panel 

The ground test panel (GTP) was a ground version of the HXRV monitor station with additional 
GSE functions used for verification and validation testing. The similarity of the GTP to the HXRV 
monitor station allowed checkout of the monitor station functions before stack integration to the 
B-52B airplane. Shown in figure 10, the GTP components were installed on a standard rack mount 
enclosure for mobility. It was designed to interface to the research vehicle, the adapter, or the 
launch vehicle in different test configurations. This feature was attributed to the use of similar 
interface connectors on the HXRV, HXA, and HXLV. Ground test panel cable harnesses were 
built to connect to the rear of the HXRV, the adapter GSE panel, the rear of the HXA, and the 
HXLV/B-52B pylon interface to provide flexibility without any additional test support equipment. 
A decommutation computer, similar to the one on the HXRV monitor station, was also part of this 
support equipment. The GTP had a 28 V, 3 kW power supply for the vehicle avionics and a 150 V, 
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20 kW power supply for the actuation system. Select GTP functions, including power control and 
emergency vent and purge functions, were also made accessible through a remote panel that could 
be located up to 100 ft away from the HXRV. This feature was required for personnel safety during 
test operations that exercised the HXRV fuel systems at full operating pressure. 



Figure 10. Ground test panel (right) with decommutation computer (left). 


The Fuel Servicing Cart 

The fuel servicing cart (FSC) provided silane, hydrogen, and nitrogen gas servicing and 
de-servicing functions for the HXRV. The FSC, pictured in figure 11, was designed to interface 
with the bulkhead of the HXRV or the adapter access panel. It had a 28 V power supply and a 
decommutation computer so that all of the fluid servicing tasks could be performed standalone. 
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Figure 11. Hyper-X fuel servicing cart. 


VERIFICATION OVERVIEW 

A brief overview of the verification process is provided to help the reader understand where 
verification ends and validation begins for the Hyper-X project. Verification is the process of 
assuring that the product (hardware or software) meets the design requirements. The verification 
process is formulated to minimize risk to flight hardware by testing individual hardware and 
software systems before performing integrated validation tests. 

Having a thorough, well thought out verification program is vital to the validation testing 
performed by NASA because verification planning and testing dictates vehicle integration. If 
verification is not thoroughly completed, part of that verification effort will be absorbed into the 
validation effort as additional tests, which could delay the project schedule. If the verification is 
not performed properly and the hardware is allowed to continue to validation testing, deficiencies 
may be uncovered that could require verification retesting and hardware disassembly. 

Hardware Verification Testing 

Hardware verification is the process of confirming that the hardware meets performance 
and functional design requirements as listed in project documentation. For the Hyper-X program, 
verification testing included all vendor-provided acceptance and qualification testing, in addition 
to functional checkouts after the systems were installed on the vehicle. The verification test plan 
was developed to first identify each individual test and the requirements driving it (ref. 8), and then 
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to select the appropriate phase of the integration flow for the test to be performed. The resulting 
hardware test flow is shown in figure 12. 

The Hyper-X verification responsibility was divided among the program’s integrated product 
teams (IPTs). Each IPT performed verification testing of their respective systems, including bench- 
level testing of the integrated systems before installation on the vehicle. The initial vehicle system 
integration and verification activities occurred at ATK-GASL, followed by final integration, 
verification, and validation activities at DFRC. 
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Figure 12. Verification test flow. 


17 







Software Verification Testing 


Software verification is defined as the process of assuring that the software meets the 
requirements as defined in the software requirements specification (ref. 9). Verification included 
module-level testing, integration testing, and closed-loop testing. The purpose of module-level 
testing was to verify individual software modules using a series of functional tests that exercised 
each element. Integration testing was performed to ensure that modules functioned properly 
when combined. This was done by installing modules on the target processor and testing each 
module-to-module interface. Closed-loop testing for the Hyper-X OFP involved simulating the 
mission profile from separation through engine bum to splashdown with the software loaded on 
the FMU. This test, also known as a qualification test, determined whether the software could be 
released to NASA as a flight-qualified OFP. 

In general, the verification testing occurred at Boeing and the validation testing at NASA, 
although some verification activities were performed by DFRC and some cursory validation was 
done by Boeing. This approach provided some cross check between the two organizations. Both 
facilities used similar (but not identical) simulation hardware, software, and data acquisition 
systems. The main reason for not having identical hardware was because of hardware availability 
and schedule issues at the different facilities. 

To expedite both verification and validation testing, it was necessary to incorporate changes 
into the software as quickly as possible. To facilitate this, NASA and Boeing generated multiple 
interim releases, called engineering releases, prior to formal release of the qualified OFP. These 
engineering releases did not require the formal qualification process prior to release; however, 
each had a Version Description Document (VDD) to allow tracking. If a problem was found during 
testing, it took only two or three days to test the options and implement the software change. When 
necessary, Boeing gave NASA engineers a “Not For Flight” version of the software via a secure 
server so that a one-day turnaround could be achieved without further testing. This concurrent 
development process allowed for early detection of problems before the flight-qualified software 
was released. The vehicle integration testing and software qualification testing was able to continue 
without any major delays. 

The NASA Hyper-X project software manager participated in nearly all qualification testing. 
The Boeing quality assurance (QA) representative was present for all qualification tests. Engineers 
from NASA and members of two independent verification and validation teams also observed a 
portion of the tests. After testing, the results were given to the Boeing Systems Group to analyze. 
A delta qualification test was required to address changes to the code identified after qualification 
testing. 


VALIDATION PLANNING 

Validation is defined as the process of assuring that the design (hardware and software) 
meets mission requirements for the intended environment as defined by project-level objectives. 
Validation for the Hyper-X project included nominal and off-nominal testing on systems that were 
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truly representative of the flight hardware and software. Different flight conditions were simulated 
to evaluate the performance and response of the software and hardware. 

The Hyper-X flight systems validation program was designed to achieve several high-level 
validation objectives derived from project top-level requirements (ref. 10). These objectives 
included the following: 

• Validate the HXRV flight systems operation from B-52B separation through splashdown 
using the nominal trajectory, separation, physical, and measurement models. 

• Validate the HXRV flight systems operation from B-52B separation through splashdown 
using trajectory, separation, physical, and measurement models that generate high 
levels of dispersion from the nominal trajectory. 

• Validate that the individual HXRV systems (hardware and software) perform as one 
integrated system in closed-loop testing. 

• Validate the HXRV flight systems response to identified failure modes. 

• Validate the engine performance in closed-loop testing with inert gases and gases 
molecularly similar to the real fuel and ignitor. 

• Validate the performance of the RF systems, including the GPS, C-band transponder, 
and S-band telemetry system. 

From these top-level requirements and objectives, a comprehensive flight systems validation 
test plan was developed to identify the tests needed (ref. 11). Additional sources for the plan 
came from system-level requirements created by the project and principal investigators; objectives 
and requirements documents generated by the discipline leads; derived requirements; failure 
modes and effects analyses; and interface control documents. The plan presented an overview, 
defined the objectives, and described the purpose of each test. It also listed the expected duration, 
test configuration, required facility, and ground test equipment. As test cases were designed to 
achieve validation objectives, they were also logically pooled to eliminate duplication. Where 
appropriate and feasible, tests were combined to fall in line with assembly, schedule, and hardware 
availability. 


An integrated test flow, shown in figure 13, was developed to assist in planning the tests 
necessary to accomplish the validation objectives. The flow reflected a gradual increase in test 
complexity as systems were validated and combined with other systems in more comprehensive 
tests. Shown in the test flow are the software engineering release philosophy and the concurrent 
validation tests that occurred in parallel with other validation test activities. Program schedulers 
used the integrated test flow as a high-level overview of the validation test progress. The validation 
test plan, along with the integrated test flow, provided the necessary milestone inputs to the 
Hyper-X program schedule. 
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Additional HIL testing in parallel 
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Figure 13. Mach 7 validation test flow. 


After the test plan and flow were completed, the responsible organizations wrote the test 
procedures. These procedures were then peer reviewed by the project and contractor team members 
to flush out any errors or inconsistencies. Corrections to the procedures were made and then signed 
off by the cognizant and responsible project leads. 

Validation Tests 

Prior to validation testing, the all-software simulation tests were conducted first to establish 
the “truth” data set. Starting from the flow diagram shown in figure 13, the first validation test 
that occurred after vehicle delivery to DFRC was the HIL test. The FMU hardware and software 
research algorithms were tested and compared against the all-software simulation results. Hardware- 
in-the-loop testing was considered successful when the data matched closely to the truth set for the 
primary engine experiment phase. 
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After HIL testing, the failure modes and effects test (FMET) was conducted. Possible failures 
to the HXRV VMS, EFS, and separation functions were introduced. This test helped point out any 
unexpected fault conditions that could compromise the mission. It provided a way of identifying 
system design deficiencies. 

Following FMET, the HXRV was connected to the simulation bench in theaircraft-in-the-loop 
(AIF) configuration. The AIF setup provided a method of testing the real vehicle hardware and 
validating the VMS, EFS, IS, and PDS systems. The VMS and PDS systems were first tested in 
the loop, followed by the IS and EFS. The gradual method of bringing multiple HXRV systems 
online provided a way of alleviating problems before complex tests were conducted. This buildup 
approach minimized retests. Data from the AIL testing were compared against the HIL and truth 
data sets. 

Subsequent to the AIL validation were the plugs-out test, FMU van test, software timing, 
power characterization, and antenna pattern tests. The plugs-out test was used to identify masked 
anomalies by removing the simulation from the loop. The FMET van test checked for FMU GPS 
and inertial navigation system (INS) operation in a dynamic environment. The software timing test 
was used to measure the computational, filter, and transport delays of the FMU so that simulation 
models used for the validation effort could be refined. Validation of the 28 V and 150 V battery 
performance for a nominal mission was demonstrated in the power characterization test. The S- 
band and C-band systems link margin and coverage were assessed in the antenna pattern test. 

Once the HXRV was thoroughly validated, the vehicle integration, combined system, captive 
carry, and flight tests were conducted. The integration tests validated the HXRV, HXA, and HXLV 
separation, cooling, and purge hardware, which were coupled systems. The combined system test 
exercised all RF and power systems, and the captive carry flight, which was a “dress rehearsal” of 
the flight test, validated the EFS, VMS, RF, IS, and PDS at launch conditions. The flight test was 
the final validation of the project objectives and requirements. 

The following sections give detailed descriptions of these tests. Where appropriate, summaries 
of test results are provided. Check out of the ground support equipment occurred before the start 
of the validation testing. 


Hardware-In-the-Loop Test 

The purpose of HIL testing was to validate the hardware and software performance of the 
FMU. For these tests, the FMU was connected to the simulation bench, depicted in figure 14. The 
CD ATS computer recorded the data output from the OFP While running the HIL configuration, 
the simulation computer hosted all models with the exception of the PSC, guidance, navigation, 
and control algorithms; they were hosted by the FMU. Inertial sensor data was provided to the 
FMU by the ISRS from a simulated INS model. The objectives of this test were to: 
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• Evaluate the performance of the FMU guidance, navigation and control laws. 

• Evaluate the performance of the FMU propulsion system algorithms. 

• Characterize the FMU performance with nominal and off-nominal trajectory 
simulations. 

• Compare HIE test runs against the all-software simulation runs. 
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Figure 14. Hardware-in-the-loop configuration. 

The tests began with the simulated HXRV attached to the launch vehicle held at specific 
initial conditions (altitude, bank, pitch, heading, latitude, longitude). The simulation provided 
the real FMU with zero velocity data for the given initial conditions. The simulated vehicle was 
essentially “suspended” in air. This was accomplished by a function in the simulation computer 
that allowed the FMU to align itself to static initial conditions without the need to acquire GPS 
satellite data. It provided a convenient way of running through each simulation case without 
the extra time required for GPS information. The simulation began when the alignment was 
complete. A B-52B separation was initiated using the SID, followed by a simulated stack boost to 
Mach 7 or Mach 10 flight conditions. To accomplish this, the FMU used a precalculated force 
and moment profile to mimic acceleration to the desired Mach number. Once the stack reached 
the separation conditions, the simulated launch vehicle “ready to separate” signal was sent to the 
HXRV FMU. The FMU responded three seconds later with the “separate command.” When the 
simulation computer detected this command, relays for the “separation sense” signal within the 
SID were switched open. The loss of this signal indicated a successful separation to the FMU. The 
engine experiment was then executed. Following the experiment, the vehicle performed research 
maneuver sets to acquire aerodynamic and flight controls research data along its descent into 
the water. These descent research maneuvers included Parameter Identification (PID) maneuvers, 
frequency sweeps, and push-over pull-up (POPU) maneuvers (ref. 5). 

Each HIE run was compared to the truth data from the all- software simulation. In addition 
to mission success analysis, sensor and actuator commands sent by the FMU were evaluated to 
ensure that the sensors were not overdriven and that none of the rudders and wings surfaces came 
into contact with each other. 
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Two nominal and 24 off-nominal trajectory cases were selected and tested for Ship 1. The 
test results demonstrated that the nominal trajectory cases matched the all-software baseline 
simulations. Off-nominal cases matched adequately during the first 100 s after the separation 
event, but then began to drift from the baseline. Since this occurred after the engine experiment, 
the project determined that the drift was acceptable because the primary objectives were not 
compromised. During that time, the deviations were attributed to time delays within the test setup 
and the inability to obtain the exact initial conditions between the HIL and all- software runs prior 
to the boost event. The team spent time investigating and found nothing to indicate the research 
vehicle would lose control during its free-flight mission. 

A major obstacle encountered during HIL testing was getting the ISRS computer and the 
simulation computer to synchronize, process, and send the trajectory data to the FMU without 
stale frames. This problem was inherent in the test setup and was attributed to differences in base 
operating frequencies between the ISRS, which processed data at 200.02 Hz, and the simulation 
computer, which processed data at 200 Hz. The data from the ISRS platform was dictated by 
Honeywell Inc., developers of the FMU, and included very little documentation. In attempting to 
synchronize the simulation computer to this rate, the project could not obtain better than 200 Hz 
and so accepted the stale frames that resulted. These stale frames affected the outcome of the test 
because the flight conditions of the vehicle were very dynamic. 

Hardware-in-the-loop testing for Ship 2 was performed in the same manner. Twenty-seven 
runs were conducted for Ship 2, including 3 nominal and 24 off-nominal runs. Data drift between 
the baseline and HIL data for off-nominal cases were still present (ref. 12). 

For Ship 3, 15 HIL cases were conducted: 2 nominal and 13 off-nominal. While conducting 
the first set of off-nominal cases, an error was discovered in the logic used to switch databases for 
aerodynamic uncertainties. The logic required the simulated cowl door position to reach exactly 
zero degrees; however, the calibration applied to the cowl door actuator model did not allow the 
position to precisely match that number. Upon further investigation, the error was found to only 
exist in the HIL environment (ref. 13). This error was determined to be causing the drift problems 
for the Ship 1 and 2 off-nominal HIL runs. Once the error was corrected, the HIL tests and batch 
simulation showed excellent agreement during the engine test and descent for all cases. 

The HIL tests provided a way of building confidence toward aircraft-in-the-loop (AIL) tests. 
Command signals from the flight computer that were sent to the various simulated systems, such 
as the actuators, were carefully examined to verify that the input and output requirements of 
each signal were met. In this way, potential damage to flight hardware was mitigated before AIL 
testing. 


Failure Modes and Effects Test 

Failure modes and effects testing (FMET) deals with identifying possible failure modes 
of the vehicle and introducing those failures during the test to see if the outcome matches the 
expected results. The advantage of FMET is that it helps uncover deficiencies in the system design 
or implementation. For example, if one channel of the redundant adapter separation system fails, 
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the other channel should be able to complete the separation sequence. Through FMET, one could 
disable a channel and expect that the other channel could carry out the separation sequence. If 
the test is unsuccessful, then the result would indicate a wiring problem or a design issue. Failure 
modes and effects testing is different from off-nominal testing because it deals with the response of 
the vehicle to credible failure modes or functions, rather than flight conditions that are not ideal. 

The failure modes were first derived from the project failure modes and effects analysis 
(FMEA). The objectives of FMET were then developed by creating a matrix of available system 
functions and cross-referencing them with different mission modes. After the tests were conducted, 
any second- or third-order effects that might have been missed by the FMEA were fed back to the 
project for analysis. 

For the Hyper-X program, FMET was intended to validate the flight software response to 
failure modes introduced by out-of-sequence input discretes and communications, among other 
things. Traditional hardware FMET was not performed because of the single-string nature of the 
HXRV design. Failing a control surface actuator, for example, would likely result in loss of vehicle 
control. Software, however, introduced a greater need for FMET since credible failures were most 
likely to appear in this area. Test cases included the interruption of OFP, MDF, and VPF uploads 
to ascertain if these errors would be reported by the FMU. Out-of-sequence separation commands 
and introduction of inhibits during non-inhibited modes were conducted. Also, failure of a data 
communication channel, the interruption of ongoing built-in tests, and the execution of commands 
prohibited in certain modes were included as part of FMET. 

During these tests, the vehicle was in the flight configuration, without the simulation in the 
loop. The GTP was used to simulate or impose various failures through the back of the vehicle 
bulkhead interface. It housed connectors that carried separation, built-in-test, vehicle health status, 
telemetry, and engine fuel system valve wiring. Failures of the input discretes were introduced by 
the GTP during the various mission modes (refer to figure 6). The discrete signals available on the 
GTP were used to simulate the flight interfaces that were present on the HXRV monitor station. To 
facilitate testing, the GTP had additional functions that could be used to send the HXFV separation 
commands or actuate the HXRV solenoid valves at specific points of the test sequence. 

The FMET objectives were to: 

• Interrupt the upload of the OFP, MDF, and VPF and verify the failure. 

• Introduce off-nominal separation sequence events, including failure (single and dual) 
of the B-52B separation sense, HXFV ready-to-separate signals, the HXRV separation 
commands, and/or the HXFV/HXRV separation break wires and verify response. 

• Execute the emergency purge sequence during various mission modes, and test a 
purge-command-signal failure during an otherwise nominal purge sequence. 

• Generate a failure of the navigation (NAV) mode select during various mission 
modes. 

• Test a simulated launch with the fuel system valves inhibited. 
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• Generate failure of various discrete input/output channels during various mission 
modes. 

• Generate failure of MIL-STD-1553 Bus A and/or Bus B during each vehicle mode. 
Prior to first flight, FMET identified several significant findings. They are reported below. 


Redundancy 

- Interrupting the A side of the MIL-STD-1553 data transfer between the FMU and the 
instrumentation system resulted in loss of MIL-STD-1553 data. Operating the bus in 
broadcast mode did not allow for automatic switchover to the B-bus if the A-bus failed. 
It was determined that while in broadcast mode, the MIL-STD-1553 bus was not dual- 
redundant. 

Wiring 

- The isolation inhibit and vent inhibit signals were wired incorrectly on the GTP 
because of inconsistencies between the HXRV drawings and the HXA interface control 
document (ICD). This required a wiring change to the HXA electronics before adapter 
delivery. 

- The separation signals on the GTP were wired with reverse polarity. This was because 
the color convention of the vehicle bulkhead wiring diagram was misinterpreted. This 
also required a wiring change to the HXA before delivery to maintain function with the 
launch vehicle electronics, which were also designed with the same color convention 
misinterpretation. 

Software Configuration 

- Interrupting a VPL and/or MDL during transfer could still result in the valid flag being 
set. This happened because the final record from the previous load was still considered 
valid. This resulted in a procedural change that required a VPL and/or MDL erase 
before loading. 

- Another configuration error resulted in the address bits for the LMU remote terminal 
(RT) address not being correctly set in the flight wiring harness. This resulted in the 
FMU not selecting the proper RT address for communicating with the CD ATS computer 
when CDATS is the bus controller. 

- The FMU did not boot in the proper alignment configuration. The navigation status 
flag indicated that the FMU was using a ground-compass align mode, as opposed to the 
proper GPS aided air- align mode required. 


For Ship 1, the anomalies encountered in FMET were discovered early in the validation 
process and were corrected with minimal impact. Many of the errors discovered were configuration 
errors that should have been identified during verification. However, since FMET was the first test 
performed with the vehicle and NASA-supplied test equipment, some integration anomalies were 
expected. Subsequent FMET for Ships 2 and 3 resulted in no anomalies. 
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Aircraft-In-the-Loop (AIL) Tests 


Aircraft-in-the-loop tests involve the use of actual flight hardware to characterize, validate, 
and compare system and component performance to simulated models. This section provides the 
objectives and results of the varied AIL tests conducted. 

AIL Actuation Test 

The AIL actuation tests were essentially HIL runs that included the real flight actuator 
controller and actuators as part of the test configuration, shown in figure 15. The FMU was mounted 
inside the research vehicle and connected to the simulation bench with the surface actuators added 
to the test loop. The cowl door actuator and fluid systems were not used in this configuration. 
The GTP attached to the rear of the vehicle through the HXRV aft bulkhead (VBA 144) and 
provided external 150 V power for the actuators and 28 V power for the actuator controller and 
vehicle avionics. Pulse code modulation (PCM) telemetry data from the FMU was collected by a 
decommutation computer. 
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Figure 15. Aircraft in-the-loop configuration. 


The objectives of AIL actuation tests were to: 

• Evaluate FMU input and output signals to the flight control surface actuators. 

• Validate guidance, navigation, and control laws with the FMU and actuators in the 
loop. 
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Characterize the performance of the actuators using nominal and off-nominal trajectory 
simulations. 

Compare simulation actuator models against real hardware. 


For Ship 1, two nominal and three off-nominal trajectory cases were tested, similar to the HIL 
tests. The real actuator command and feedback signals compared well with the simulation models 
for Ship 1. A stable 3 Hz dither was observed on the actuator positions, P, Q, Phi, and angle of 
attack (ref. 14). The amplitude for the actuation dither was about 0.1° peak-to-peak. Simulation 
results indicated that even with this phenomenon present, the vehicle was stable and able to meet 
mission requirements. For Ships 2 and 3, dither was also present during AIL testing (ref. 12). 
After extensive research, the cause was traced to the actuator pulse width modulation (PWM) 
dead band that coupled with non-linearities such as time delay and noise occurring in the AIL test 
environment (refs. 14-15). As a check, the nonlinear elements were modeled in the all-software 
simulation, and dither was successfully replicated prior to Ship 2 taking flight. Predictions with 
updated models had indicated that dither would not be present during flight. 

Since the surfaces were not loaded during AIL testing, actuator deadband was present. 
Although loaded tests using bungee cords were conducted early in the program, the configuration 
was not adequate in taking out the deadband. The risk of damaging flight hardware prevented 
the use of other loading systems for the AIL tests. Dither was not seen in the flight data for the 
Mach 7 and 10 flights. The dead band was essentially removed by the aerodynamic forces on the 
surfaces. 

Overall comparison between HIL and AIL runs exhibited good matches for all signals except 
sideslip (ft) and heading (ys ) angles. Ultimately, the team’s misunderstanding of the FMU gyro 
and accelerometer sensors caused the discrepancies. These deviations could further be attributed 
to improper accounting for winds, initial use of low-fidelity FMU sensor models, test environment 
nonlinearities, and incorrect selection of aerodynamic uncertainties. When the project received 
a validated sensor model from Honeywell and changed the criteria for switching aerodynamic 
uncertainties, the simulation analysis errors were corrected. 

AIL Blowdown Tests 

The next step after the AIL actuation tests was the validation of the PSC algorithms using 
an inert gas (GN2) and a semi-real gas (GN2/H2) mixture. All flight systems were used for these 
tests, including the cowl door actuator and fluid systems. The objectives of these two blowdown 
tests were to: 

• V alidate the performance of PSC software using flight hardware in a nominal trajectory 
simulation. 

• Validate the performance of fuel and ignitor motorized control valves and SVs. 

• Gain experience in handling and servicing high pressure gases. 
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AIL Inert Blowdown Test 


The inert blowdown test used gaseous nitrogen for the GH2, silane, and GN2 purge tanks. 
The hydrogen fuel and GN2 purge tanks were serviced to 8450 psi. The silane ignitor tank was 
serviced with GN2 to 4450 psi, and the HXRV coolant tank was filled with de-ionized water. 
The simulation bench provided the inertial navigation data and the HXLV separation commands. 
External 28 V and 150 V power was supplied by the GTP. 

The Mach 7 fuel sequence is given here as an example of what happens during the inert gas 
test. Like all other HIL and AIL tests, the HXRV and simulated stack are held at specific initial 
conditions. After LMU alignment and stack boost, the simulated “ready to separate” signal is sent 
to the HXRV. Seconds later, the LMU opens the nitrogen tank SV to initiate compartment purge 
and supply coolant tank pressure. The coolant valve then opens to release the de-ionized water 
through the engine sidewalls and cowl door. About three seconds elapse before the LMU sends 
the “separate command” to the simulated HXLV. The research vehicle separation break wires are 
disconnected by the simulation computer to mimic the separation event. The LMU then transitions 
into the engine experiment mode in which the cowl door is commanded open, and the LMU PSC 
software performs the engine experiment. Engine zero fuel reference measurements are taken for 
a few seconds. The ignitor SV and MCV are opened, releasing the inert GN2 into the engine. Less 
than a second later, the fuel SV and MCV are opened, releasing the inert GN2. The gases are mixed 
at the engine Y-block, released through the injectors, and exhausted out of the engine. The ignitor 
sequence ends first, and the valve is closed while the fuel sequence continues for a longer duration 
before it is terminated. The engine run time is less than 10 s. The actuation system performs the 
engine open PID maneuver and closes the cowl door upon completion (ref. 7). 

At the end of the engine experiment, any gases remaining inside the fuel and ignitor systems 
are vented out of the engine. The purge blowdown immediately follows the vent sequence. This 
function ensures that the vehicle does not carry explosive gases into the ocean. Before simulated 
splashdown, additional PIDs and frequency response maneuvers are performed. 

The inert blowdown results of vehicle 1 indicated that the software met its objectives 
(refs. 9-10) and commanded the engine experiment sequence as expected. The vehicle hardware 
performed nominally and operated within tolerance of the propulsion system requirements 
(ref. 16), with the exception of the coolant solenoid valve. It did not operate in the correct sequence, 
and during the test, the valve released water when it was not turned on. After some investigation, 
it was discovered that the coolant valve was installed in the wrong direction. The installation was 
done according to print, so the conclusion was made that the drawings were incorrect. In addition, 
this error had caused back pressure impingement on the water tank, which was not expected to 
happen. All of these discoveries led to a hardware redesign for the cooling system which included 
correcting the valve orientation and adding a check valve to prevent any back pressure from 
damaging the water tank. A “walkdown” inspection of fluid system hardware with respect to the 
design flow path may have prevented this installation error. Inert gas testing on Ships 2 and 3 were 
the same and yielded nominal results. 
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AIL Semi-Real Gas Blowdown Test 


The hardware configuration for the semi-real gas blowdown test remained the same as the 
test described previously. The only difference was that the hydrogen tank was serviced with 
100 percent H2 and the ignitor tank was serviced with 77 percent GN2 and 23 percent GH2 to 
simulate the molecular weight of silane. (In real flight, the ignitor tank was serviced with a mixture 
of 20 percent silane SiH4 and 80 percent GH2 by volume.) The objectives of the semi-real gas test 
were to: 

• Determine the fuel motorized control valve performance using hydrogen instead of 
nitrogen. 

• Determine the ignitor motorized control valve performance using a mixture of nitrogen 
and hydrogen to simulate silane flow rate characteristics. 

• Provide a final validation of the PSC software. 


The test was conducted for Ship 1 in the same fashion as the inert blowdown test discussed 
previously. The test software was confirmed to operate per propulsion system requirements 
(refs. 9, 16), and the hardware performed nominally. The test was successful in validating the 
performance of the PSC software as well as the fuel and ignitor MCVs. Additional semi-real gas 
testing was not required for Ships 2 and 3. 

Plugs-Out Test 

The purpose of the plugs-out, or standalone, test was to validate the system performance in 
the flight configuration, without the simulation bench connected. Although this test is unique to 
satellites and other types of spacecraft, the project felt that benefits could be gained by adopting it 
into the validation program. The primary intent was to eliminate any anomalies that may have been 
disguised by the simulation interface with the flight systems. 

The plugs-out test was also used to demonstrate electromagnetic compatibility between 
the HXRV systems since all RF systems, including the GPS, S-band telemetry, and C-band 
transponders, were turned on. As an added benefit, this test served as a flight day rehearsal for 
control room operations. 

The objectives of this validation test were to: 

• Evaluate the HXRV flight systems performance without the simulation in the loop. 

• Flow gases through the real engine injectors. 

• Measure system noise levels and transmission delays. 

• Characterize power system performance. 

• Evaluate vehicle operation in a realistic RF environment. 
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• Validate the end-to-end telemetry system performance. 

• Exercise the day-of-flight operations procedures. 


The internal HXRV battery provided primary power (28 V and 150 V) for the HXRV during 
the plugs-out test. The GTP was the only ground support equipment connected to the vehicle during 
the test. It was used to simulate power normally provided by the B-52B airplane during ground 
operations and captive carry. The GTP also simulated the prelaunch functions normally supplied 
by the HXRV monitor station, and served as the interface for triggering the separation signals. 

The vehicle fuel systems were pressurized to less than operating pressure with inert gases. 
The lower pressures were chosen to minimize safety risk and speed up fueling operations without 
compromising test objectives. A telemetry van was used to acquire the S-band data, and a 
C-band interrogator was used to stimulate the onboard C-band transponder. The test procedure was 
designed to follow the day-of-flight operations, using the actual flight card sequences. 

The vehicle was transitioned through the mission modes via the separation signals provided by 
the GTP. Test data was compared with results from pretest predictions to evaluate any differences in 
performance attributable to the simulation being in the loop. Test results of the first research vehicle 
indicated an anomaly in the performance of the fuel system MCV. The plugs-out configuration 
resulted in combinations of off-nominal conditions that caused the propulsion control algorithm to 
default to an open-loop sequence. This open-loop default was not expected and was inconsistent 
with pretest predictions. 

Further investigation determined that the flow rate characteristics of this flight valve were 
significantly different than that of the valve used in bench tests. The nominal inert blowdown tests 
conducted previously did not uncover the problem since the characterization difference alone was 
not enough to force open-loop control. All of these findings led to the modification of the OFP 
software to allow uploadable coefficients that could accommodate motorized control valves with 
different performance characteristics. Since there were no significant system interface changes to 
the follow-on vehicles, this test was not required for Ships 2 or 3 (ref. 17). 

Flight Management Unit Van Test 

The van test was devised to subject the FMU to motion so that the outputs of the inertial 
measurement unit (IMU), as seen through the flight application software, could be verified. The 
output data were positions, angles, rates, and accelerations. Prior to the van test, all trajectory tests 
were performed with the ISRS in the loop to simulate the FMU IMU outputs. The integration 
testing performed by the contractor did not include any checks of dynamic outputs of the FMU 
because the verification testing was performed with the FMU stationary on the test bench. This 
was a crucial risk reduction test that had to be performed before further validation testing could 
proceed. The objectives of the test were to: 
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• Subject the FMU to dynamic motion while executing the Hyper-X operational flight 
program. 

• Activate the flight control logic by moding the software through the carried, 
preseparation, experiment, and descent modes. 

• Verify the position and attitude reference frames are consistent through the navigation, 
flight control, and guidance algorithms. 

• Verify transition of the FMU through the alignment and navigation modes. 

• Verify operation of the GPS with the antenna connected in the flight configuration. 


Power to the FMU was provided by a 28V power supply that plugged into a rack-mounted 
uninterrupted power supply. A loopback test harness was connected to the FMU so that the navigation 
mode could be switched from a GPS-IMU blended navigation solution to a pure inertial solution 
when required. The CD ATS computer was used to collect navigation and moding information from 
the FMU over the MIL-STD-1553 data bus. The GPS antenna from the HXRV was mounted to the 
top of the van using the actual vehicle skin panel. This was done to make a qualitative assessment 
of the attenuation through the TPS. The GPS antenna was located in the HXRV skin panel, below 
the thermal protection tile. The van was driven through varying altitudes and directions, and was 
accelerated in multiple directions. 

The van test successfully demonstrated that the FMU state outputs were correct. The test 
data from Ship 1 was directly applicable to flights 2 and 3; therefore, this test did not have to be 
repeated (ref. 17). 


Software Timing Test 

The software timing test was performed to assess the transport and computational delay found 
in the HIL and AIL environments and to quantify those delays found in the flight configuration 
(ref. 18). There were two main reasons for conducting this characterization test. First, there was 
the possibility that dither seen during Ship 1 AIL testing (refer to the AIL testing section) was 
caused by unmodeled time delays. Second, the simulation models did not account for FMU OFP 
execution time delays and therefore required test data for model refinement. The objectives of the 
software timing test were to: 

• Determine the transport, computational, and execution time delays of the FMU OFP. 

• Understand the effects of time delays in the HIL and AIL test environments. 

• Improve the fidelity of the X-43A simulation used for validation testing. 


The timing tests used a special OFP build that supplied execution timing for functions of 
interest. After this OFP was loaded into the FMU, HIL tests were performed to quantify timing 
for filters, read and send routines, as well as start and finish function calls. To develop the overall 
closed-loop system delay, this data was combined with FMU IMU sensor delays and actuator 
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command to first wing motion timing obtained from an EMA characterization test. The results 
were implemented in the all-software simulation and then averaged until the states matched those 
seen in HIL and AIL configurations. This test helped identify time delay as one of the contributors 
to the dither phenomenon seen during AIL testing. The updated all-software simulation was then 
used for more accurate pre flight analyses (ref. 18). 

Power Characterization Test 

The HXRV battery was sized to accommodate the loads expected during flight. To validate 
battery performance and minimize impact to the test flow, power data was collected during selected 
validation tests. Time history of the current data for the 150 V and 28 V systems were acquired 
by attaching current probes to the battery leads. Voltage data was measured directly from the two 
voltage buses. The objectives of this test were to: 

• Validate the performance of the 28 V and 150 V flight batteries. 

• Quantify the voltage and current characteristics of the battery for a nominal mission 
profile so that it could be used as a reference for other validation tests involving the 
power distribution system. 


Lor the first vehicle, a flight battery designated for ground testing only was characterized 
during the AIL inert blowdown test and the plugs-out test (ref. 19). The battery performance met 
the mission requirements. This test was not required for the second and third vehicles because 
there were no significant changes to the system components or vehicle operations for flight. 

Antenna Pattern Test 

The purpose of this test was to gather qualitative antenna pattern data from the HXRV RL 
system to fulfill project requirements for link margin and coverage specifications (ref. 10). The 
RL system had to maintain adequate gain and link coverage between the ground and air assets 
throughout the entire mission operation. This requirement was verified and validated by collecting 
antenna patterns at selected elevation angles of the HXRV. The objectives were to: 

• Verify and validate the RL system for adequate gain and coverage. 

• Determine the positioning of the P-3 Orion airplane (Lockheed Martin, Bethesda, 
Maryland) antenna relative to the HXRV for best RL reception. 


Since Ship 1 was being used for other validation testing, ATK-GASL provided the second 
HXRV flight test vehicle for the antenna testing. As seen in figure 16, the vehicle was flight-like 
in its configuration, with the control surfaces, TPS, antennas, signal splitters, and associated RL 
cabling installed. The engine was also in place and the cowl door opened to simulate the vehicle in 
the engine experiment phase. The carbon-carbon leading edges of the tungsten nose normally used 
for flight were substituted with geometrically similar wooden edges to prevent damage. 
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Figure 16. Antenna pattern testing in the Benefield Anechoic Facility at Edwards Air Force Base. 

The original RF system design consisted of one S-band transmitter input to a three-way 
splitter and routed to three S-band antennas (two side antennas and one aft antenna). The C-band 
beacon transponder was fed into a three-way splitter and then to the three C-band antennas (two 
sides, one aft). The HXRV was tested at 5 look-down angles (0, 5, 10, 45, and 75 degrees) and 1 
look-up angle (5°). The look-down angles were chosen as possible angles seen by ground antennas 
and the P-3 airplane antennas. Measurements were made first with all antennas connected and then 
with only two side antennas connected. With all antennas connected, the generated antenna plots 
demonstrated that the antenna patterns were not constant over the field of view of the antenna. 
Null areas followed by high gain lobes, called grating lobes, were created by superposition of 
waveforms caused by the presence of the aft mounted antenna. Testing with only the two side 
antennas verified that the aft antenna was the source of the superposition. The antenna cables from 
the antennas to the combiner were measured for phase matching. One cable was found to be at 
least 45° out of phase when compared to the others. It was replaced and each band was brought to 
within 13° of phase match between cables. This correction, however, did not eliminate the grating 
lobes created by the presence of the aft antenna. 

To correct this undesired effect, a separate dedicated S-band transmitter was added for the 
aft antenna. The two side antennas remained on the original transmitter. This new configuration 
increased the output power at the side antennas. Anew PCM module was added to the instrumentation 
system to provide PCM data to the aft antenna transmitter. The aft transmitter was only activated 
after the HXRV separated from the HXLV. To eliminate interference problems with the C-band 
transponder system, a decision was made to leave the C-band aft antenna disconnected. 
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The modifications changed the antenna radiation patterns of the vehicle, which required 
another test to provide a qualitative assessment of the RF coverage. The retest demonstrated that 
the pattern achieved was sufficient. The data collected was used to properly assign the P-3 Orion 
aircraft flight positions so that during the course of the mission, RF coverage could be maintained. 
Since the S-band and C-band antenna positions did not change for the other research vehicles, the 
antenna pattern test was only performed once. 

Stack Integration Tests 

To assemble the FIXRV, HXA, and HXLV so that they could be properly integrated with 
the B-52B airplane, a series of integration tests were performed. They were conducted after 
each configuration buildup - first in the short stack (HXRV/HXA) stage, then in the full stack 
(HXRV/HXA/HXLV) stage, and finally in the captive stack (HXRV/HXA/HXLV/B-52B) stage, 
as shown in figure 17. Each test was conducted after the electrical mate of the vehicles and then 
again after the mechanical mate. 



Figure 17. Captive stack configuration. 
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Short Stack (HXRV/HXA) Tests 


The short stack configuration is shown in figure 18. The objectives of the short stack integration 
tests were to: 

• Check the integrity of end-to-end wiring for the HXRV/HXA. 

• Verify that the HXRV GSE functions are operational after integration. 

• Verify the HXRV health monitoring and mission critical functions are operational after 
integration. 

• Validate the hardware performance of the HXRV and HXA cooling and purge systems 
for the separation event. 



VBA 215 bulkhead 
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Figure 18. Short stack configuration. 


Prior to HXRV and HXA integration, continuity and isolation checks were performed on 
the wiring cables of both vehicles. The HXRV and HXA were brought together using two engine 
dollies and then electrically mated. Continuity and isolation tests were conducted at the adapter 
GSE panel and at the rear adapter bulkhead (VBA 215). The GTP was then connected to the GSE 
service panel, and all GSE functions were verified with the FMU installed in the research vehicle. 
These functions included power switching, built-in test discretes, analog inputs, PCM telemetry 
data, vent/purge commands, and HXRV valve controls. 
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Short Stack Pass-Through Cable Tests 

The rear adapter bulkhead, VBA 215, contained a number of cables that passed health 
monitoring and mission critical signals from the research vehicle to the HXLV and the B-52B 
airplane. The health monitoring signals, which were routed to the HXRV monitor station on the 
bomber, were essentially the same GSE functions as used in the short stack tests. Mission-critical 
signals such as the separation discretes were verified at the rear adapter bulkhead. 

After the functional tests were completed, the research vehicle was then mechanically mated 
to the adapter. To confirm that no wires had been crimped or damaged during this process, the 
functional tests were repeated. 

Short Stack Integrated Cooling and Purge Test 

The objective of the integrated cooling and purge test was to validate the timing of the 
HXRV coolant and GN2 purge solenoid valves at the time of separation. For a nominal mission, 
the HXA coolant and purge systems are active throughout the boost phase. Since the transfer of 
these functions to the HXRV does not occur until just before separation, the fluids system handoff 
between the two vehicles must be examined carefully. If the HXRV coolant and purge valves are 
opened too early prior to separation, a pressure transient will occur within the HXRV fluids system 
because of the combined GN2 pressure from the adapter and research vehicle. Opening these 
valves as close as possible to the separation event minimizes the likelihood of this unfavorable 
pressure transient. It also ensures sufficient coolant flow until separation. 

For this test, the HXRV cooling tank was filled with de-ionized water, and the HXA cooling 
tank was filled with a 60 percent ethylene glycol, 40 percent water mixture. The HXRV and HXA 
purge tanks were serviced with GN2 at 8450 and 4800 psi, respectively. The GN2 system supplied 
pressure to the cooling tanks in addition to compartment purge pressure for the HXRV during 
boost and flight. 

The GTP was used to provide the HXFV “ready to separate” command to the HXRV. It was 
connected to the back of the rear adapter bulkhead, and a breakout box was used to supply this 
signal to the HXRV and a PC controller/relay box. The PC controller was used to simulate the 
physical separation event by shutting down the HXA coolant and purge valves 3 s after receipt of 
the “ready to separate” signal. 

For monitoring the adapter tank pressures and temperatures, a data acquisition unit was 
attached to the adapter instrumentation plug. The test setup is shown in figure 19. 
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Figure 19. HXRV/Adapter integrated cooling and purge test configuration. 


One cooling and purge test was performed for Ship 1. Measurements of the remaining coolant 
within both vehicles indicated adequate margin for the mission. Two tests were performed for Ship 
2 because of a timing change that controlled when the HXA coolant and purge valves would open. 
During the first test, the scale used to weigh the remaining coolant didn’t yield accurate results 
because of poor resolution on the device (ref. 20). The worst case margin calculated using this 
scale was deemed unacceptable and created the need for a second blowdown test in which a more 
accurate calibrated scale was used. One test was conducted for Ship 3 and results met the required 
margins. For all vehicles, timing and valve sequencing were within the predicted limits. 

Full Stack (HXRV/HXA/HXLV) Tests 

The objectives of the full stack integration tests were to: 

• Verify and validate the separation logic between the HXRV and the HXLV. 

• Verify and validate the ordnance timing and wiring of the integrated stack. 

• Check the telemetry and flight termination system (FTS) of the HXLV. 

• Verify and validate HXRV health monitoring and mission critical functions after 
integration. 


Similar to the short stack integration, a standalone checkout of the HXLV electrical system was 
performed prior to mating it with the short stack. Each wire harness was verified for continuity and 





isolation. In addition, the ordnance systems and separation logic of the HXLV and HXRV vehicles 
were tested separately because these two systems were critical to the success of the mission. The 
HXLV was tested for ordnance detonation timing. This was accomplished by sending multiple 
test cases of the simulated HXRV “separate command” to the HXLV flight control computer and 
verifying that the detonation commands were sent to the ordnance cable. These cases included 
nominal, early and late timing signals, as well as single and dual channel failures. A dummy 
ordnance box with 1-ohm resistors was used in place of the real pyrotechnics. 

Once the standalone tests were completed, the HXRV/HXA and HXLV vehicles were 
electrically mated. A nominal power up check for the HXLV telemetry system was performed. From 
the adapter GSE service panel, the HXRV avionics were turned on using the GTP and a validation 
test of the separation logic was then conducted using both vehicles. No mission simulation was 
involved at this point. To test the redundancy built into the separation system, each channel was 
tested independently and then together. The separation sequence was initiated by the HXLV ground 
test equipment. 

The next test, called the “zero volts” test, involved turning on all RF transmitters and power 
sources of the HXLV and the HXRV while each separation-related signal path was inspected at the 
ordnance interface. The zero volts test was performed to verify that there were no stray voltages 
caused by the RF or avionics power systems. Sensitive meters, known as blaster’s meters, were 
used to detect the presence of extremely low voltage signals. 

Only one of the FTS functions was verified in this configuration since the full verification was 
the responsibility of the HXLV team. The HXLV was designed to initiate the FTS if a premature 
HXRV separation was detected. This function was verified by disconnecting premature separation 
sense wires through the use of breakout boxes. 

Full Up Separation Logic/Ordnance Tests 

Full up separation tests normally start with a simulated stack drop from the B-52B bomber. 
This event causes the HXLV inertial navigation system (INS) simulator to pass nominal launch 
vehicle trajectory data to the HXLV flight control computer. The coolant and purge pyrotechnic 
valves in the HXA are opened at preprogrammed times by the HXLV. When the full stack reaches 
the target flight conditions, the separation logic communication occurs between the launch vehicle 
and research vehicle. The ordnance driver module (ODM) initiates all separation ordnances after 
receiving the HXRV separation commands and the ordnance pulses are sent to the dummy ordnance 
box. One second after separation, the launch vehicle commands purge depressurization valves to 
open in the HXA. 

A total of three simulation runs were performed: the first with “ready to separate” channel A 
only, then channel B only, and finally the nominal A and B case. Ordnance timing from the data 
was carefully evaluated to ascertain that the separation timing requirements were met. All of these 
tests were conducted without pressurized gases, and dummy load resistors were used in place of 
the actual coolant and purge valves. 
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During the first full stack testing for Ship 1, the ordnance time delay measured was 40 ms, 
instead of the 5 ms requirement. It was discovered that the ordnance initiation call in the HXLV 
software was made at the end of a computational cycle, rather than at the beginning. A software 
change was made and the new test results showed a two ms time delay, which was well within the 
requirement. For Ships 2 and 3, the full up separation tests were successful. No anomalies were 
found. 

Full Stack Pass Through Cable Tests 

The same test conducted for the HXRV health and mission critical signals during the short 
stack integration were repeated for this configuration. The only difference was the placement of 
the GTP, which was connected at the interface between the HXLV and B-52B pylon adapter. Here, 
all HXRV monitor station functions were verified in the same manner as discussed in the short 
stack section. 

After the HXLV and short stack were mechanically mated, the telemetry, FTS, full up 
separation logic/ordnance tests, and pass through cable tests were repeated. No anomalies were 
found for the three vehicles. 

Captive Stack (HXRV/HXA/HXLV/B-52B) Tests 

The HXRV monitor station was used to check out the health monitoring and mission functions 
instead of the GTR All tests were performed after the electrical mate and then repeated after the 
mechanical mate of the full stack to the B-52B airplane. The objectives of the captive stack test 
were to: 

• Mate the full stack to the B-52B airplane in preparation for the combined system test 
(CST), captive carry, and flight test. 

• Ensure that the HXRV health monitoring and mission critical functions are 
operational. 


No major issues were found for any of the vehicles. 

Combined Systems Test 

The CST occurred after the captive stack testing. During the CST, B-52B power transitions 
tests from ground to aircraft power were conducted while the HXRV and HXLV systems were 
kept online by their onboard batteries. The purpose was to determine if there were any adverse 
effects on the vehicle systems caused by carrier aircraft power transients. The HXRV and HXLV 
actuator surface BITs were executed; all transmitters were turned on; and data was observed from 
the control room. The test objectives for the CST were to: 
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• Conduct power on and power off sequences for all vehicles using the day-of-flight 
procedures. 

• Evaluate the performance of the captive stack while all RF systems are turned on and 
determine if there are any RF electromagnetic interference (EMI)/electromagnetic 
compatibility (EMC) problems. 


No power, RF EMI, or EMC issues were present for any of the vehicles. 

Captive-Carry Test 

The captive carry involved an actual flight to the point of launch from the B-52B airplane. 
All flight day activities, including vehicle preflight, fluid system servicing (with inert gases), and 
prelaunch activities were performed. Flight go/no-go calls were made from the control room using 
the day-of-flight procedures. The main objectives for the captive-carry test were to: 

• Verify overall HXRV system health and data quality at flight conditions. 

• Provide training for all ground personnel for day-of-flight activities. 

• Evaluate B-52B airplane performance. 

• Verify coordination activities between multiple range assets. 

• Rehearse flight operations with all flight test teams (primary and auxiliary). 

• Demonstrate that the oxygen intrusion levels of the HXRV are less than 1.5 percent (to 
minimize risk of fire caused by silane leakage). 

• Demonstrate that there are no EMI/EMC issues. 


The first vehicle captive-carry mission was successful. The second vehicle captive carry was 
held approximately one month prior to flight. Besides minimal delays caused by weather, the 
captive-carry mission was successful. Two attempts were made before the vehicle 3 captive-carry 
mission took place. The first two attempts were halted because of problems with hydraulic packs 
on the B-52B airplane. On the third attempt, Ship 3 experienced a number of GPS anomalies that 
eventually lead to bad inertial and blended navigation data for the flight. This was attributed to the 
GPS time drift within the FMU during the B-52B power transfer from ground to aircraft source. 
During this process, the GPS signal that was fed into the FMU (from the top of the B-52B wing) 
was removed to protect the GPS hardware from power transients while the B-52B alternators were 
brought online. It would normally take about three minutes to complete the transfer, but during 
this particular mission it took six minutes. The blackout caused the FMU internal GPS time to 
drift, resulting in lagged estimates of GPS data. Once the GPS signal was restored, the Kalman 
filters within the FMU began to reject true GPS data because it did not fall within the estimated 
parameter boundaries. Since this anomaly occurred just prior to takeoff, the decision was made 
to continue with the mission. During flight, the FMU reported erroneous blended and inertial 
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navigation data and continued to reject GPS data. After the B-52B airplane landed, the anomalies 
were investigated and corrective actions were implemented. 

To prevent another GPS blackout, a temporary backup battery was used to keep the GPS 
online during the B-52B power transfer. Also, FMU power cycle opportunities were defined in the 
flight cards to allow adequate alignment time for the FMU inertial navigation system and to gauge 
when it was too late to meet the launch time window. For the captive-carry test, the minimum 
success criteria were to demonstrate minimum oxygen intrusion levels and the absence of EMI/ 
EMC problems. Since both criteria were met, the captive-carry mission was not repeated to verify 
the INS/GPS data. Those parameters were evaluated using data from Ship 3 ground testing. Also, 
they could be monitored in real time during the captive portion of the actual flight. 

Flight Test 

Following captive-carry validation of each vehicle, the flight test was conducted. The first 
vehicle mission was on June 2, 2001. There was a mishap during this mission that resulted in the 
loss of the full stack shortly after launch from the B-52B airplane. The HXLV failed to boost the 
HXRV to its flight conditions. The mishap investigation board reported, “that the HXLV control 
system was deficient for the trajectory flown due to inaccurate analytical models (Pegasus heritage 
and HXLV specific), which overestimated the system margins” (ref. 21). The HXLV fin actuation 
models and aerodynamic modeling used for mission simulation studies were not representative of 
the true system and environments. The failure of the launch vehicle was not related to the HXRV 
or any testing described in this report. 

On March 27, 2004, the second vehicle flew into the record books with a successful flight 
test. The third vehicle experienced instrumentation issues on the first attempt and had its successful 
flight on November 16, 2004 (ref. 22). The results of these flights can be found in the program’s 
flight reports and the chief engineer’s report (ref. 2). 

LESSONS LEARNED 

The evolving nature of verification and validation testing provides many opportunities to 
leam from and improve upon test planning methodology. This section offers some of the lessons 
learned by the Hyper-X team in preparation for flight. 

Planning 

A sound validation test plan is essential to the success of a research program. The most valuable 
aspect of the HXRV flight systems validation program was up-front planning. A comprehensive 
plan addressing the validation objectives was critical to allocating program resources towards 
developing thorough tests and accomplishing the test goals. 


Once an acceptable validation plan was completed, the requirements for ground support 
equipment (GSE) were defined. The GSE was developed with flexibility in mind to sufficiently 
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address the various testing needs of the program. It was important that the GSE be able to 
accommodate additional test requirements as validation issues surfaced. 

The use of the ground test panel (GTP) for testing different vehicle configurations helped 
immensely to cut down GSE cost and fabrication time. All of the ground functions were combined 
to create the ground test panel. Similar interface connectors for the HXRV, HXA, and HXLV were 
used so that the GTP could be mated to them at any stage with a minimal amount of cable change. 
In addition, the flight test functions of the HXRV monitor station were built into the test panel, 
which allowed the flight test engineer to become familiar with the monitor station functions prior 
to flight. 

Several different flight configurations were achieved throughout testing, and each one presented 
its own potential risks and advantages. To minimize the risks and capitalize on the advantages of 
each configuration, the project scheduled tests in a build-up approach. Tests were performed such 
that once cables were connected they didn’t have to be disengaged to perform subsequent tests. 
This minimized the probability of bent connector pins. During validation planning, the project also 
identified the need to establish a process for delivering engineering software releases to support 
integration testing. The use of engineering releases for prototyping between qualified builds sped 
development and facilitated testing. 

Although validation planning precluded many issues associated with vehicle integration 
and testing, the Hyper-X flight systems validation program would have benefited from a more 
comprehensive verification process. The validation process was complicated by configuration 
errors found in the HXRV following delivery to NASA. These errors, identified during failure 
modes and effects testing, resulted in recoding of the simulation and redesign of test equipment 
that had already been fabricated. More oversight of the verification process could have prevented 
the vehicle from being delivered with discrepancies. 

Reviews and Inspections 

Early in the design process, systems experts should review the system design to decrease 
the likelihood of finding design deficiencies late in the integration phase. For example, the pattern 
deficiencies found during the antenna pattern test should have been identified sooner in the research 
vehicle design process. Unfortunately, antenna configuration experts with design knowledge were 
not consulted until the problem was identified during the testing. If resources permit, bring in 
specialized consultants early in the project to help create good specifications before hardware 
procurement. 

Also, a peer review of the FMU to instrumentation system MIL-STD-1553 data bus design 
would have identified the single-string nature of using the MIL-STD-1553 broadcast mode. 
Although problems like this can sometimes be found using prototypes or simulations, the best way 
is often to bring in the system experts. 
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The discovery of the HXRV water coolant valve installation error during the first inert gas test 
led to a slight modification of the cooling system. This error could have been avoided if an audit 
of the drawings was performed along with a thorough inspection of the assembled system with 
respect to the fluid flow path. 

Recognized standards, such as wiring polarity with respect to color, should have been 
established between team members earlier in the program. This could have been accomplished 
with a comprehensive audit of the vehicle drawings and the system interface control documents. 

Development and Testing 

Testing has a direct impact on project schedule and cost, and, as such, it must be performed 
efficiently. The X-43A validation plan took advantage of the opportunity to get high value data 
with minimal impact. The test plan allowed engineers to combine multiple test objectives into 
the same tests, thereby minimizing time on flight hardware and schedule required. For example, 
one test objective included the collecting of power data. Instead of this objective being fulfilled 
with a single test, it was accomplished in parallel with other tests. It is also important to note that 
tests with little schedule requirements and uncomplicated configurations can still return valuable 
test data. The FMU van test, for instance, took less than three days and verified the FMU inertial 
system operation with the real flight control laws. 

Understanding how systems react in non-optimal conditions is as important as understanding 
how they react in expected environments. For that reason, validation test planning for the Hyper-X 
program incorporated several tests to analyze the system response under non-optimal conditions. 
Off-nominal testing for the X-43A included nonoptimal initial separation conditions, such as off- 
target mach, a , /} , or control surface positions - all parameters that might have affected the engine 
performance. Testing under these conditions allowed the project to assess and refine the flight 
control, guidance, and navigation algorithms used in the FMU. 

Failure modes and effects testing on the HXRV returned many benefits. By introducing 
credible faults to the vehicle systems, this test was able to identify errors in the OFP configurable 
software functions, as well as wiring mistakes early on in the program. It also led to the discovery 
of the MIL-STD-1553 broadcast mode problem discussed earlier. The importance of failure modes 
and effects testing cannot be overstated. When design deficiencies are identified prior to hardware 
integration, schedule delays and cost increases can be easily avoided. 

The navigation anomalies encountered during Ship 3 captive carry testing were a result of 
a temporary loss of GPS signal to the HXRV FMU. This failure mode was never tested, because 
of the lack of a GPS module in the unit that was used for ground testing. The negative effects 
of temporary GPS signal loss were not discovered until the captive-carry test, which resulted in 
erroneous HXRV, GPS, and INS data. This scenario could be a problem for some flight control 
computers. If possible, it is a good idea to perform GPS blackout tests during failure modes and 
effects testing to verify that the flight control computer still operates nominally after the GPS 
signal is restored. 
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Assumptions made against test results should be thoroughly checked before the team makes 
decisions based on those results. This lesson was demonstrated during the plugs-out testing. Based 
on the assumption that the performance characteristics of the fluid systems for each of the three 
vehicles were nearly identical, the second vehicle underwent benchmark testing. In reality, the 
characteristics of the motorized flow control valves were different between vehicles. The simulation 
could not be used to identify the problem since it modeled only the performance obtained during 
the initial valve characterization testing. The project had to perform testing under the combination 
of off-nominal conditions present in the plugs-out test to uncover the differences between the 
motorized control valves of different ship-sets. 

Hardware and Redundancy 

An iron bird testbed was not incorporated into the validation program. An iron bird, which is a 
representative vehicle dedicated solely for testing, could have been used to minimize wear and tear 
on the real vehicle. By design, it should have the same hardware components as the flight vehicle 
to maintain the philosophy of “test what you fly.” Most of the validation testing for the Hyper-X 
vehicle, especially aircraft-in-the-loop tests, involved the use of the actual aircraft systems. The 
iron bird would have provided a safeguard against potential damage to flight-critical hardware. 

In addition, problems could undergo troubleshooting on the testbed and free up the vehicle for 
other uses. Testing could be performed on the iron bird while hardware assembly and integration 
occurred on the flight hardware. This might have greatly helped to reduce schedule delays. Often, 
the benefits of this approach must be weighed against cost. 

To accommodate verification testing at Boeing and validation testing at DFRC, fabrication of 
two identical test benches was planned. In reality, the two benches were not completely identical, 
a fact that complicated troubleshooting when anomalies were encountered. The timing of the 
hardware procurement contributed to this issue. Although the need for two benches was greatly 
desired for efficiency, more effort should have been made to ensure that the hardware for the 
benches was truly equivalent. 


Software System Interface 

For the Hyper-X program, a critical test validation interface was the networking of simulated 
navigation data through the Inertial Sensor Recorder/Simulator (ISRS) to the FMU. This is 
the process whereby simulation-generated flight conditions are passed to the FMU to validate 
vehicle performance at realistic flight conditions. The ISRS is a commercial product supplied by 
Honeywell Inc. and, as such, interfacing to the simulation computer was expected to be simple. 
In reality, the interface issues were complicated and not well documented. Much time and effort 
was spent attempting to resolve errors in properly formatting and transferring the simulated flight 
conditions between the computers . If the true noncommercial nature of the ISRS had been understood 
early in the program, more resources could have been dedicated to solving the problems. 
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CONCLUSION 


A sound validation test plan is essential to the success of a research program. Testing has a 
direct impact on project schedule and cost and, as such, must be performed efficiently. Though 
many factors contributed to the success of the Hyper-X program, the most critical aspect of the 
HXRV flight systems validation program was up-front planning. A comprehensive plan addressing 
the validation objectives was critical to allocating program resources towards accomplishing the 
test goals. 

The Hyper-X vehicle is unique but characteristic of the next generation of aerospace vehicles. 
The flight systems validation plan presented is derived from past experience with testing both 
aircraft and spacecraft systems. The plan is reflective of the concurrent engineering that is common 
with integrating vehicles in a rapid prototyping environment. 

Encouraging both the development of combined tests that accomplish multiple objectives and 
performing minimal impact tests with high return are critical to minimizing risk and optimizing 
schedule. Developing a plan for using software engineering releases is critical to support integration 
testing and maintain schedule, since relying on qualified software for every test can be inefficient. 
Developing requirements for ground support equipment after the validation plan was completed 
ensured production of GSE that sufficiently addressed the testing needs. Additionally, the use of 
one ground test panel for testing different vehicle configurations helped reduce GSE cost and 
fabrication time. 

The lessons learned during Hyper-X flight systems validation are not revolutionary. They have, 
however, demonstrated the need to address fundamental design and integration issues early in the 
design process. The tests uncovered both mission critical anomalies and noncritical performance 
related anomalies. Discovering and correcting these anomalies demonstrated the effectiveness of 
the validation plan. Recommendations mentioned include peer review of preliminary designs; 
focused effort on creating accurate drawings and ICDs; and design of ground test equipment that 
is flexible in meeting test objectives. It is also necessary to allocate the proper time and resources 
to address integration issues with commercially supplied simulation hardware, especially when the 
hardware interfaces are not well documented. Another lesson learned is to thoroughly understand 
the test environment characteristics so that the test data is not misinterpreted or attributed to 
problems with the vehicle systems. Hopefully, by presenting the Hyper-X flight systems validation 
plan and the lessons learned during the validation process, the process for follow-on vehicles 
will benefit. 
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